Feature Flags: Der ultimative Leitfaden zur dynamischen Feature-Kontrolle in der modernen Softwareentwicklung

In der heutigen schnelllebigen digitalen Landschaft war der Druck, innovative Software schnell und zuverlässig zu liefern, noch nie so groß. Für globale Organisationen wird diese Herausforderung durch die Notwendigkeit, unterschiedliche Benutzergruppen zu bedienen, komplexe Infrastrukturen zu verwalten und verteilte Teams zu koordinieren, noch verstärkt. Das traditionelle Modell großer, seltener, risikoreicher Bereitstellungen ist nicht mehr tragfähig. Es schafft Engpässe, führt zu Instabilität und verlangsamt die Feedbackschleife, die für iterative Verbesserungen unerlässlich ist.

Hier kommen Feature Flags ins Spiel, auch bekannt als Feature Toggles. Diese leistungsstarke Technik revolutioniert die Art und Weise, wie Software erstellt, getestet und veröffentlicht wird. Durch die Entkopplung von Code-Bereitstellung und Feature-Freigabe bieten Feature Flags ein beispielloses Maß an Kontrolle, Sicherheit und Flexibilität für Entwicklungs-, Produkt- und Geschäftsteams. Sie verwandeln Releases von einer Quelle der Angst in eine kontrollierte, risikoarme und sogar routinemäßige Geschäftsaktivität.

Dieser umfassende Leitfaden beleuchtet die Welt der Feature Flags von grundlegenden Konzepten bis hin zu fortgeschrittenen Strategien. Wir behandeln, was sie sind, warum sie für die moderne Entwicklung unverzichtbar sind, wie man sie effektiv implementiert und welche Best Practices Ihre Organisation befähigen, global schneller und sicherer zu innovieren.

Was sind Feature Flags? Eine grundlegende Übersicht

Im Kern ist ein Feature Flag ein Entscheidungspunkt in Ihrem Code, der das Verhalten der Anwendung ändern kann, ohne dass eine neue Code-Bereitstellung erforderlich ist. Stellen Sie es sich als Fernbedienung oder eine ausgeklügelte 'if'-Anweisung vor, mit der Sie Features für alle Benutzer, bestimmte Benutzersegmente oder sogar einzelne Benutzer in Echtzeit ein- oder ausschalten können.

Eine einfache Implementierung von Feature Flags sieht in Pseudocode so aus:

            
if (featureFlags.isNewCheckoutProcessEnabled()) {
  // Zeige die neue, verbesserte Checkout-Erfahrung
  showNewCheckoutProcess();
} else {
  // Zeige die alte, stabile Checkout-Erfahrung
  showOldCheckoutProcess();
}

            

              
                Copy
              
            
          

Der Zauber liegt darin, wie der Wert von isNewCheckoutProcessEnabled() bestimmt wird. Anstatt ein fest kodierter boolescher Wert (true oder false) zu sein, wird sein Zustand extern verwaltet – oft über eine Benutzeroberfläche oder eine API. Diese Trennung ist der Schlüssel, der eine breite Palette leistungsstarker Entwicklungs- und Release-Strategien ermöglicht.

Die Kernkomponenten eines Feature-Flag-Systems

• Das Flag: Eine Variable, die ein bestimmtes Feature darstellt. Sie hat einen Zustand (ein/aus oder eine Variante wie 'blau', 'grün', 'rot') und Targeting-Regeln.
• Der Entscheidungspunkt: Die 'if'-Anweisung in Ihrem Code, die den Zustand des Flags prüft und das Verhalten der Anwendung entsprechend anpasst.
• Die Management-Konsole: Eine Benutzeroberfläche (UI) oder ein Dashboard, über das nicht-technische und technische Teammitglieder die Zustände und Regeln der Flags verwalten können, ohne den Code zu berühren.
• Das SDK (Software Development Kit): Eine Bibliothek, die in Ihre Anwendung integriert ist und mit dem Managementsystem kommuniziert, um die neuesten Flag-Regeln effizient und zuverlässig abzurufen.

Warum Feature Flags für globale Teams unerlässlich sind

Feature Flags sind mehr als nur ein Werkzeug für Entwickler; sie sind ein strategisches Asset für jede Organisation, die es mit agiler Entwicklung und kontinuierlicher Bereitstellung ernst meint. Hier sind die Gründe, warum sie für moderne, global verteilte Teams so entscheidend sind.

Entkopplung von Bereitstellung und Freigabe

Dies ist der grundlegendste Vorteil. Traditionell bedeutete die Bereitstellung von Code, dass die darin enthaltenen Features gleichzeitig für alle Benutzer freigegeben wurden. Dies führte zu risikoreichen, stressigen Release-Nächten. Mit Feature Flags können Sie neuen, unvollständigen oder experimentellen Code sicher 'ausgeschaltet' in die Produktion bereitstellen. Der Code ist auf den Servern live, aber für die Benutzer inaktiv. Die Feature-Freigabe wird zu einer separaten, bewussten Geschäftsentscheidung, die durch das Umlegen eines Schalters in einer Management-Konsole getroffen wird, völlig unabhängig vom Zeitplan für die Engineering-Bereitstellung.

Risiken mit Kill Switches und Progressive Delivery mindern

Jedes neue Feature birgt Risiken. Es könnte einen Fehler enthalten, unter Last schlecht performen oder Benutzer verwirren. Feature Flags fungieren als Sicherheitsnetz.

• Kill Switch: Wenn ein neu veröffentlichtes Feature Probleme verursacht – vielleicht stürzt die Anwendung für Benutzer in einer bestimmten Region ab oder überlastet eine Datenbank – können Sie es mit einem einzigen Klick sofort für alle deaktivieren. Dies reduziert die mittlere Wiederherstellungszeit (MTTR) von Stunden (was eine Rollback-Bereitstellung erfordert) auf nur Sekunden.
• Progressive Delivery: Sie können ein Release risikominimieren, indem Sie es schrittweise einführen. Beginnen Sie damit, es für interne Mitarbeiter zu aktivieren, dann für 1 % Ihrer Benutzerbasis, dann für 10 %, 50 % und schließlich für 100 %, während Sie gleichzeitig Leistung und Feedback überwachen. Dies wird auch als Canary Release bezeichnet.

Beschleunigung von Entwicklungszyklen und CI/CD

Feature Flags sind ein Eckpfeiler moderner CI/CD-Pipelines (Continuous Integration und Continuous Delivery). Sie ermöglichen es Teams, Code häufiger in den Hauptzweig (Trunk) zusammenzuführen, auch wenn die Features noch nicht vollständig sind. Indem sie unvollständige Arbeiten in ein 'ausgeschaltetes' Flag einschließen, vermeiden Entwickler den Albtraum langlebiger Feature-Branches, deren Zusammenführung schwierig und riskant ist. Diese Praxis, bekannt als Trunk-Based Development, reduziert Merge-Konflikte erheblich und hält den Code des gesamten Teams jederzeit integriert und bereit zur Bereitstellung.

Produktions- und Geschäftsteams stärken

Feature Flags demokratisieren das Release-Management. Produktmanager können ein neues Feature perfekt im Einklang mit einer Marketingkampagne einführen, ohne eine Ticket-Anfrage an das Engineering zu stellen. Das Marketingteam kann ausgewählten Influencern frühzeitigen Zugang gewähren. Das Vertriebsteam kann einem wertvollen Kunden während einer Demo ein Premium-Feature aktivieren. Diese Ausrichtung von Geschäftszielen auf technische Fähigkeiten fördert unglaubliche Agilität.

Arten von Feature Flags: Eine Taxonomie für strategische Implementierung

Nicht alle Flags sind gleich. Das Verständnis der verschiedenen Arten von Flags und ihrer Lebensdauer ist entscheidend für die Aufrechterhaltung eines sauberen und überschaubaren Systems. Wir können sie nach ihrem Zweck kategorisieren.

1. Release-Toggles

Dies ist die häufigste Art von Flags. Sie werden verwendet, um unvollständige Features vor Benutzern zu verbergen, während der Code in die Produktion gebracht wird. Sie ermöglichen Trunk-Based Development, indem sie es Entwicklern ermöglichen, unfertige Arbeiten sicher hinter einem Flag zusammenzuführen.

• Zweck: Entkopplung von Bereitstellung und Freigabe.
• Lebensdauer: Kurzfristig. Sobald das Feature vollständig freigegeben und stabil ist, sollte das Flag und die damit verbundene bedingte Logik aus dem Code entfernt werden, um technische Schulden zu vermeiden.
• Beispiel: Eine neue Benutzerprofilseite wird über mehrere Sprints hinweg erstellt. Der Code wird in den Main-Branch integriert und kontinuierlich bereitgestellt, aber das Flag [new-user-profile-page-enabled] bleibt 'ausgeschaltet', bis es zur Markteinführung bereit ist.

2. Experimentier-Toggles (A/B- oder multivariate Tests)

Diese Flags werden verwendet, um mehrere Varianten eines Features zu testen, um zu sehen, welche Variante im Vergleich zu einer bestimmten Metrik (z. B. Konversionsrate, Benutzerbindung) besser abschneidet. Sie leiten verschiedene Benutzersegmente zu unterschiedlichen Code-Pfaden.

• Zweck: Datengesteuerte Produktentwicklung.
• Lebensdauer: Mittelfristig. Sie existieren für die Dauer des Experiments. Sobald ein Gewinner ermittelt ist, wird das Flag entfernt und der gewinnende Code-Pfad zum Standard.
• Beispiel: Ein E-Commerce-Shop möchte zwei Knopffarben für seinen Button "In den Warenkorb" testen. Das Flag [cart-button-color-experiment] liefert 'blau' für 50 % der Benutzer und 'grün' für die anderen 50 %.

3. Ops-Toggles (Kill Switches)

Dies sind sicherheitsorientierte Flags, die zur Steuerung operativer Aspekte des Systems verwendet werden. Sie ermöglichen es Betreibern, ein nicht-essentielles, aber ressourcenintensives Feature schnell zu deaktivieren, wenn es die Systemstabilität beeinträchtigt.

• Zweck: Steuerung von Systemstabilität und Leistung.
• Lebensdauer: Langfristig oder permanent. Sie sind Teil des operativen Werkzeugkastens des Systems.
• Beispiel: Ein neuer Empfehlungsalgorithmus ist rechenintensiv. Das Flag [enable-realtime-recommendations] kann während Spitzenverkehrszeiten deaktiviert werden, um Serverressourcen zu schonen und auf eine einfachere, weniger intensive Version zurückzugreifen.

4. Berechtigungs-Toggles

Diese Flags steuern, welche Benutzer Zugriff auf bestimmte Features haben. Dies wird häufig für Premium-Features, Beta-Programme oder interne Tests verwendet. Sie ermöglichen eine feingranulare Kontrolle über die Benutzererfahrung basierend auf Benutzerattributen.

• Zweck: Verwaltung von Benutzerberechtigungen und Zugriff.
• Lebensdauer: Langfristig oder permanent. Sie sind ein integraler Bestandteil der Geschäftslogik des Produkts.
• Beispiel: Eine SaaS-Anwendung verwendet ein Flag [enable-advanced-reporting-feature], das nur für Benutzer mit dem "Enterprise"-Abonnementplan 'eingeschaltet' ist.

Implementierung von Feature Flags: Ein praktischer Leitfaden

Es gibt verschiedene Möglichkeiten, Feature Flags zu implementieren, von einfachen fest kodierten Werten bis hin zu hochentwickelten, global verteilten Management-Plattformen. Die richtige Wahl hängt von der Größe Ihres Teams, der Komplexität Ihrer Anwendung und Ihren spezifischen Bedürfnissen ab.

Level 1: Die grundlegende 'If'-Anweisung (im Code)

Dies ist die einfachste Form, aber auch die am wenigsten flexible. Der Zustand des Flags ist direkt im Quellcode fest kodiert.

            
const isNewFeatureEnabled = false; // oder true

if (isNewFeatureEnabled) {
  // Code für neue Funktion
}

            

              
                Copy
              
            
          

• Vorteile: Extrem einfach zu implementieren.
• Nachteile: Völlig unflexibel. Eine Änderung des Flag-Zustands erfordert eine Codeänderung, einen neuen Build und eine neue Bereitstellung. Dies untergräbt den Hauptzweck der Entkopplung von Bereitstellung und Freigabe.

Level 2: Verwendung einer Konfigurationsdatei

Ein bedeutender Schritt nach oben ist die Verlagerung des Flag-Zustands aus dem Code in eine Konfigurationsdatei (z. B. eine JSON-, YAML- oder .properties-Datei), die die Anwendung beim Start liest.

config.json:

            
{
  "new-user-profile-page-enabled": true,
  "realtime-recommendations-enabled": false
}

            

              
                Copy
              
            
          

Anwendungscode:

            
if (config.get('new-user-profile-page-enabled')) {
  // Feature-Code
}

            

              
                Copy
              
            
          

• Vorteile: Für das Umschalten einer Funktion ist keine Codeänderung erforderlich. Einfacher für Systemadministratoren zu verwalten.
• Nachteile: Erfordert normalerweise einen Neustart der Anwendung oder eine Rollout-Bereitstellung, um die Änderungen zu übernehmen. Unterstützt kein dynamisches Targeting (z. B. Einschalten für bestimmte Benutzer). Die Änderung ist 'alles oder nichts' für eine gegebene Serverinstanz.

Level 3: Eine selbst gehostete Datenbank oder ein Key-Value-Store

Für eine dynamischere Kontrolle können Sie Flag-Konfigurationen in einer Datenbank (wie PostgreSQL) oder einem schnellen Key-Value-Store (wie Redis) speichern. Ihre Anwendung würde dann diese Quelle periodisch nach den neuesten Flag-Zuständen abfragen.

• Vorteile: Änderungen können zentral vorgenommen und ohne Neustart auf alle Anwendungsinstanzen übertragen werden. Kann komplexere Regeln unterstützen.
• Nachteile: Sie müssen die Management-UI und die zugrunde liegende Infrastruktur selbst erstellen und warten. Dies umfasst die Bewältigung von Leistung, Skalierbarkeit, Sicherheit und Audit-Protokollierung, was einen erheblichen Engineering-Aufwand bedeuten kann.

Level 4: Dedizierte Feature-Flag-Management-Plattformen

Dies ist der leistungsstärkste und skalierbarste Ansatz. Er beinhaltet die Nutzung eines Drittanbieterdienstes (SaaS) oder einer umfassenden Open-Source-Lösung. Diese Plattformen bieten eine vollständige Suite von Tools zur Verwaltung von Flags.

• Beispiele: Kommerzielle Plattformen wie LaunchDarkly, Optimizely und Flagsmith; Open-Source-Lösungen wie Unleash.
• Wie es funktioniert: Sie integrieren ein leichtgewichtiges SDK in Ihre Anwendung. Dieses SDK ruft Flag-Regeln vom globalen, latenzarmen Content Delivery Network (CDN) der Plattform ab und speichert sie im Arbeitsspeicher. Entscheidungen werden lokal und sofort getroffen, ohne externe Aufrufe im Anforderungspfad. Wenn Sie ein Flag in der UI ändern, wird die Änderung in Echtzeit an alle verbundenen SDKs gestreamt.
• Vorteile:
  • Echtzeit-Updates: Schalten Sie einen Schalter um und sehen Sie die Änderung global in Millisekunden.
  • Erweitertes Targeting: Zielen Sie auf Benutzer basierend auf beliebigen Attributen: Standort, Abonnementebene, E-Mail-Adresse, Browser, Gerät oder benutzerdefinierte Anwendungsdaten.
  • Benutzerfreundliche UI: Ermöglicht nicht-technischen Teammitgliedern die Verwaltung von Releases und Experimenten.
  • Skalierbarkeit und Zuverlässigkeit: Diese Plattformen sind darauf ausgelegt, Milliarden von Flag-Auswertungen pro Tag zu verarbeiten.
  • Audit-Protokolle und Analysen: Verfolgen Sie jede Änderung und messen Sie die Auswirkungen von Features.
• Nachteile: Erfordert in der Regel Abonnementkosten für kommerzielle Plattformen. Führt eine Abhängigkeit von einem externen Dienst ein (obwohl SDKs für einen sicheren Fallback entwickelt sind).

Erweiterte Strategien und globale Anwendungsfälle

Mit einem robusten Feature-Flagging-System können Sie über einfache Ein/Aus-Schalter zu ausgefeilteren Release-Strategien übergehen.

Progressive Delivery und Canary Releases

Stellen Sie sich vor, Sie führen eine kritische neue Zahlungsabwicklungsintegration ein. Ein Fehler hier könnte massive finanzielle Auswirkungen haben. Anstelle eines 'Big Bang'-Releases können Sie Feature Flags für einen kontrollierten, progressiven Rollout verwenden.

1. Phase 1 (Intern): Aktivieren Sie das Feature nur für interne Mitarbeiter (z. B. Targeting von Benutzern mit einer E-Mail-Adresse `@ihre Firma.com`).
2. Phase 2 (Canary): Veröffentlichen Sie das Feature für 1 % Ihrer gesamten Benutzerbasis. Überwachen Sie Fehlerquoten, Leistungskennzahlen und Support-Tickets genau.
3. Phase 3 (Regionale Einführung): Erweitern Sie die Freigabe auf 25 % der Benutzer, vielleicht targeting eines bestimmten Landes oder einer bestimmten Region, um Lokalisierung und regionale Infrastruktur zu testen. Dies ist für globale Produkte von unschätzbarem Wert.
4. Phase 4 (Vollständige Freigabe): Wenn Sie zuversichtlich sind, erhöhen Sie die Benutzerzahl auf 100 %.

In jeder Phase können Sie bei Erkennung eines Problems die Prozentzahl mit dem Kill Switch sofort auf 0 % zurückstellen und die Auswirkungen sofort eindämmen.

Verwaltung von Abonnement-Stufen und Berechtigungen

Für SaaS-Produkte mit unterschiedlichen Preisstufen (z. B. Kostenlos, Pro, Enterprise) sind Feature Flags das perfekte Werkzeug zur Verwaltung von Berechtigungen. Anstatt komplexer, fest kodierter bedingter Logik in Ihrer gesamten Anwendung zu verwenden, können Sie eine einzige Quelle der Wahrheit haben.

            
// Prüfen, ob der Benutzer einen Plan hat, der erweiterte Analysen beinhaltet
if (featureFlags.isEnabled('advanced-analytics', { user: currentUser })) {
  // Zeige das Dashboard für erweiterte Analysen
}

            

              
                Copy
              
            
          

Auf Ihrer Feature-Flag-Management-Plattform würden Sie eine Regel für das Flag 'advanced-analytics' erstellen: "Aktivieren für jeden Benutzer, bei dem das Attribut 'plan' 'Pro' oder 'Enterprise' ist." Dies macht es unglaublich einfach zu verwalten, welche Features in welchem Paket verfügbar sind und sogar Testläufe durchzuführen, indem ein Benutzer vorübergehend zu einem bestimmten Segment hinzugefügt wird.

Umgang mit technischen Schulden: Der Flag-Lebenszyklus

Eines der größten Risiken bei der Verwendung von Feature Flags ist die Ansammlung technischer Schulden. Eine Codebasis, die mit alten, veralteten Flags für Features übersät ist, die vollständig gestartet oder aufgegeben wurden, wird schwer lesbar und wartbar. Eine erfolgreiche Feature-Flagging-Strategie muss einen Plan für die Flag-Entfernung beinhalten.

Legen Sie einen klaren Lebenszyklus für Ihre Flags fest:

1. Erstellung: Ein neues Flag wird mit einem klaren Namen und einer Beschreibung erstellt. Kennzeichnen Sie es als entweder temporär (z. B. Release Toggle) oder permanent (z. B. Ops Toggle).
2. Implementierung: Das Flag wird dem Code hinzugefügt.
3. Rollout: Das Flag wird zur Verwaltung der Feature-Freigabe verwendet.
4. Bereinigung: Sobald ein temporäres Flag seinen Zweck erfüllt hat (das Feature zu 100 % freigegeben und stabil ist), sollte ein Ticket für technische Schulden erstellt werden, um das Flag und die gesamte damit verbundene bedingte Logik aus der Codebasis zu entfernen, sodass nur der gewinnende Code-Pfad übrig bleibt.

Viele Feature-Flagging-Plattformen verfügen über integrierte Tools, die helfen, veraltete Flags zu identifizieren, die seit längerer Zeit denselben Varianten für alle Benutzer ausliefern.

Best Practices für eine robuste Feature-Flagging-Strategie

Um die Vorteile zu maximieren und die Risiken zu minimieren, befolgen Sie diese weltweit anerkannten Best Practices:

• Klare Namenskonventionen festlegen: Ein Flag namens new_thing ist nutzlos. Ein Name wie [checkout-team][new-paypal-integration][release] ist viel besser. Er teilt Ihnen das Team, das Feature und den Zweck des Flags mit.
• Flag-Management zentralisieren: Verwenden Sie ein einziges, einheitliches System als Quelle der Wahrheit für alle Flags. Dies verhindert Verwirrung und Fragmentierung zwischen Teams und Diensten.
• Rollenbasierte Zugriffskontrolle (RBAC) verwenden: Nicht jeder sollte ein Flag in der Produktion ändern dürfen. Definieren Sie Rollen (z. B. Betrachter, Bearbeiter, Administrator), um zu steuern, wer Flags in verschiedenen Umgebungen (Entwicklung, Staging, Produktion) ändern darf.
• Beide Flag-Zustände testen: Ihre automatisierten Tests (Unit-, Integrations-, End-to-End-Tests) sollten für den 'Ein'- und 'Aus'-Zustand eines Flags ausgeführt werden, um sicherzustellen, dass beide Code-Pfade wie erwartet funktionieren und das alte Feature durch das neue nicht beeinträchtigt wird.
• Leistung überwachen: Moderne Feature-Flag-SDKs sind für hohe Leistung ausgelegt und treffen Entscheidungen aus einem In-Memory-Cache. Es ist jedoch dennoch ratsam, potenzielle Latenzen zu überwachen und sicherzustellen, dass Ihr System optimal funktioniert.
• Für Fallback sorgen: Was passiert, wenn Ihr Feature-Flagging-Dienst nicht verfügbar ist? Ihre Anwendung sollte nicht abstürzen. Ein gutes SDK verfügt über einen Standard- oder Fallback-Mechanismus, der in der Regel den zuletzt bekannten guten Wert oder einen vordefinierten Standardwert liefert.
• Strategisch vorgehen, nicht alles flaggen: Das Flaggen trivialer Änderungen kann unnötige Komplexität hinzufügen. Konzentrieren Sie sich auf das Flaggen von benutzergerichteten Features, risikoreichen Backend-Änderungen, Infrastrukturmigrationen und allem, was Sie unabhängig von einer Bereitstellung steuern möchten.

Die Zukunft der Softwareentwicklung ist dynamisch

Feature Flags stellen einen grundlegenden Wandel in der Art und Weise dar, wie wir über die Softwarebereitstellung denken. Sie bewegen uns weg von monolithischen, risikoreichen Release-Ereignissen hin zu einem Modell der kontinuierlichen, kontrollierten und datengesteuerten Feature-Bereitstellung. Indem sie den technischen Akt der Bereitstellung vom geschäftlichen Akt der Freigabe trennen, ermöglichen sie es Teams, bessere Produkte schneller und mit weniger Risiko zu entwickeln.

Für globale Organisationen ist diese Fähigkeit kein Luxus, sondern eine Wettbewerbsnotwendigkeit. Sie ermöglicht es ihnen, marktspezifische Features zu testen, eine komplexe Matrix von Berechtigungen zu verwalten und die Systemstabilität über eine verteilte Infrastruktur aufrechtzuerhalten, während sie gleichzeitig mit der Geschwindigkeit agieren, die der moderne Markt verlangt.

Erste Schritte

1. Klein anfangen: Wählen Sie für Ihre erste Implementierung ein einzelnes, nicht kritisches Feature. Lernen Sie den Workflow kennen und demonstrieren Sie den Wert für Ihr Team.
2. Das richtige Werkzeug wählen: Bewerten Sie, ob eine einfache Konfigurationsdatei für den Moment ausreicht oder ob der Umfang und die Komplexität Ihrer Anforderungen eine dedizierte Plattform rechtfertigen.
3. Das Team schulen: Feature-Flagging ist ein kultureller Wandel. Stellen Sie sicher, dass Produktmanager, QA-Ingenieure und Stakeholder aus dem Geschäft verstehen, was Flags sind und wie sie verwendet werden können.
4. Ihren Prozess definieren: Dokumentieren Sie Ihre Namenskonventionen und Ihren Plan für das Lifecycle-Management von Anfang an.

Indem Sie dynamische Feature-Kontrolle annehmen, übernehmen Sie nicht nur ein neues Werkzeug, sondern eine moderne Denkweise der Agilität, Sicherheit und kontinuierlichen Verbesserung, die die Grundlage für Innovation und Wachstum in den kommenden Jahren bilden wird.